Real-time process control systems were first implemented within a single software program executing on a single computer system. As the need to monitor and control more physical devices increased, the number and the complexity of the software programs required to accomplish this task also increased.
The earliest real-time process control software programs were constructed as a set of separate text constructs called source files. These source files were then transformed into object files and library files using software development tools. Library files contained library routines that were common to several tasks. The use of the library files prevented the programmers from having to redevelop the same routines that had already been developed.
After the software files were written and compiled, the programmers joined them together in an operation called static linking. Static linking caused all of the application programs and the library routines to be joined into a single executable file. This executable file was the program that governed operating of the real-time process control system.
Under static linking, the software development tools informed programmers when an interface incompatibility existed between routines. This allowed the programmers to correct the incompatibility problems when someone changed the interface to one of the library routines. However, static linking required the programmers to re-link all the application programs and library routines whenever a change was made to any application program or library routine.
To correct the problem of having to re-link every time an application program or library routine changed, the software industry developed dynamic linking. Dynamic linking called for the library routines to remain separate from the application programs and stored in what is called Dynamically Linked Libraries (“DLLs”). Once a particular application program actually called a particular library routine during runtime, the operating system (or the infrastructure services for embedded systems) dynamically linked the application program to the library routine. Once the application program and the library routine were dynamically linked, the library routine could perform the desired function.
Under dynamic linking, when a library routine required an update, the programmers were only required to update the DLL and not the application programs that would employ the library routine during runtime. Once the DLL was updated, the application programs could then use the updated DLL without having to perform another static linking. However, dynamic linking has its own problems.
One problem associated with dynamic linking is interface compatibility. Interface compatibility occurs when a calling software routine (“client”) communicates to a called routine (“supplier”) and the information passed is in the correct order and of the correct type. If the information is disordered or of an incorrect type, then unpredictable results can occur, compromising the integrity and operation of the real-time process control system as a whole.
Interface incompatibility can occur when a routine's interface is changed in a DLL and the application programs that use that particular DLL are not correspondingly changed. This can occur very easily, especially in complex real-time process control systems containing hundreds of application programs. What is needed in the art is a way to ensure that the interfaces of various cooperating application programs, modules or routines are compatible before the interfaces are relied upon.